General purpose compression for video images (RHN)

ABSTRACT

Methods, medium, and machines which compress, encode, enhance, transmit, decompress and display digital video images in real time. Real time compression is achieved by sub-sampling each frame of a video signal, encoding and filtering the pixel values to codes, and run-length encoding the codes. Real time transmission is achieved due to high levels of effective compression. Real time decompression is achieved by decoding and decompressing the encoded data to display high quality images. High levels of effective compression also reduce the storage space requirement for recorded video.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119(e) of the nowabandoned U.S. provisional application Ser. No. 60/113,276 filed on 1998Dec. 23, and entitled “METHOD OF IMAGES ENHANCEMENT, COMPRESSION, ANDENCODING of GRAYSCALE IMAGES (ECHOCODEC).” The provisional applicationSer. No. 60/113,276 filed on 1998 Dec. 23 and entitled “METHOD OF IMAGEENHANCEMENT, COMPRESSION, AND ENCODING of GRAYSCALE IMAGES (ECHOCODEC)”is also hereby incorporated by reference.

This application also claims priority under 35 U.S.C. §119(e) of ourco-pending U.S. patent application Ser. No. 09/312,922 filed on 1999 May17, and entitled “SYSTEM FOR TRANSMITTING VIDEO IMAGES OVER A COMPUTERNETWORK TO A REMOTE RECEIVER,” which describes an embodiment of theinvention of this application in combination with our now abandoned U.S.provisional application Ser. No. 60/085,818 filed on 1998 May 18, andentitled “APPARATUS FOR TRANSMITTING LIVE VIDEO IMAGES OVER A COMPUTERNETWORK TO MULTIPLE REMOTE RECEIVERS.” U.S. patent application Ser. No.09/312,922 filed on 1999 May 17, and entitled “SYSTEM FOR TRANSMITTINGVIDEO IMAGES OVER A COMPUTER NETWORK TO A REMOTE RECEIVER” is alsohereby incorporated by reference.

BACKGROUND

1. Field of the Invention

This invention relates to data compression, specifically to thecompression and decompression of video images.

2. Description of Prior Art

In the last few years, there have been tremendous advances in the speedof computer processors and in the availability of bandwidth of worldwidecomputer networks such as the Internet. These advances have led to apoint where businesses and households now commonly have both thecomputing power and network connectivity necessary to havepoint-to-point digital communications of audio, rich graphical images,and video. However the transmission of video signals with the fullresolution and quality of television is still out of reach. In order toachieve an acceptable level of video quality, the video signal must becompressed significantly without losing either spatial or temporalquality.

A number of different approaches have been taken but each has resultedin less than acceptable results. These approaches and theirdisadvantages are disclosed by Mark Nelson in a book entitled The DataCompression Book, Second Edition, published by M & T Book in 1996. MarkMorrision also discusses the state of the art in a book entitled TheMagic of Image Processing, published by Sams Publishing in 1993.

VIDEO SIGNALS

Standard video signals are analog in nature. In the United States,television signals contain 525 scan lines of which 480 lines are visibleon most televisions. The video signal represents a continuous stream ofstill images, also known as frames, that are fully scanned, transmittedand displayed at a rate of 30 frames per second. This frame rate isconsidered full motion. A television screen has a 4:3 aspect ratio.

When an analog video signal is digitized, each of the 480 lines issampled 640 times and each sample is represented by a number. Eachsample point is called a picture element, or pixel. A two dimensionalarray is created that is 640 pixels wide and 480 pixels high. This640×480 pixel array is a still graphical image that is considered to befull frame. The human eye can perceive 16.7 thousand colors. A pixelvalue comprised of 24 bits can represent each perceivable color. Agraphical image made up of 24-bit pixels is considered to be full color.A single second-long full frame, full color video requires over 220millions bits of data.

The transmission of 640×480 pixels×24 bits per pixel times 30 framesrequires the transmission of 221,184,000 millions bits per second. A T1Internet connection can transfer up to 1.54 millions bits per second. Ahigh speed (56 Kb) modem can transfer data at a maximum rate of 56thousand bits per second. The transfer of full motion, full frame, fullcolor digital video over a T1 Internet connection, or 56 Kb modem, willrequire an effective data compression of over 144:1, or 3949:1,respectively.

BASIC RUN-LENGTH ENCODING

An early technique for data compression is run-length encoding where arepeated series of items are replaced with one sample item and a countfor the number of times the sample repeats. Prior art shows run-lengthencoding of both individual bits and bytes. These simple approaches bythemselves have failed to achieve the necessary compression ratios.

VARIABLE LENGTH ENCODING

In the late 1940s, Claude Shannon at Bell Labs and R. M. Fano at MITpioneered the field of data compression. Their work resulted in atechnique of using variable length codes where codes with lowprobabilities have more bits, and codes with higher probabilities havefewer bits. This approach requires multiple passes through the data todetermine code probability and then to encode the data. This approachalso has failed to achieve the necessary compression ratios.

D. A. Huffman disclosed a more efficient approach of variable lengthencoding known as Huffman coding in a paper entitled “A Method forConstruction of Minimum Redundancy Codes,” published in 1952. Thisapproach also has failed to achieve the necessary compression ratios.

ARITHMETIC, FINITE CONTEXT, AND ADAPTIVE CODING

In the 1980s, arithmetic, finite coding, and adaptive coding haveprovided a slight improvement over the earlier methods. These approachesrequire extensive computer processing and have failed to achieve thenecessary compression ratios.

DICTIONARY-BASED COMPRESSION

Dictionary-based compression uses a completely different method tocompress data. Variable length strings of symbols are encoded as singletokens. The tokens form an index to a dictionary. In 1977, AbrahamLempel and Jacob Ziv published a paper entitled. “A Universal Algorithmfor Sequential Data Compression” in IEEE Transactions on InformationTheory, which disclosed a compression technique commonly known as LZ77.The same authors published a 1978 sequel entitled, “Compression ofIndividual Sequences via Variable-Rate Coding,” which disclosed acompression technique commonly known as LZ78 (see U.S. Pat. No.4,464,650). Terry Welch published an article entitled, “A Technique forHigh-Performance Data Compression,” in the June 1984 issue of IEEEComputer, which disclosed an algorithm commonly known as LZW, which isthe basis for the GIF algorithm (see U.S. Pat. Nos. 4,558,302,4,814,746, and 4,876,541). In 1989, Stack Electronics implemented a LZ77based method called QIC-122 (see U.S. Pat. No. 5,532,694, U.S. Pat. No.5,506,580, and U.S. Pat. No. 5,463,390). The output of a QIC-122 encoderconsists of a stream of data, which, in turn consists of tokens andsymbols freely intermixed. Each token or symbol is prefixed by a singlebit flag that indicates whether the following is a dictionary referenceor a plain symbol. The definitions for these two sequences are:

-   -   (a) plaintext <1><eight-bit-symbol>    -   (b) dictionary reference: <0><window-offset><phrase-length>        Windows offsets are encoded as seven bits or eleven bits. These        lossless (method where no data is lost) compression methods can        achieve up to 10:1 compression ratios on graphic images typical        of a video image. While these dictionary-based algorithms are        popular, these approaches require extensive computer processing        and have failed to achieve the necessary compression ratios.

JPEG AND MPEG

Graphical images have an advantage over conventional computer datafiles: they can be slightly modified during thecompression/decompression cycle without affecting the perceived qualityon the part of the viewer. By allowing some loss of data, compressionratios of 25:1 have been achieved without major degradation of theperceived image. The Joint Photographic Experts Group (JPEG) hasdeveloped a standard for graphical image compression. The JPEG lossy(method where some data is lost) compression algorithm first divides thecolor image into three color planes and divides each plane into 8 by 8blocks, and then the algorithm operates in three successive stages:

-   -   (a) A mathematical transformation known as Discrete Cosine        Transform (DCT) takes a set of points from the spatial domain        and transforms them into an identical representation in the        frequency domain.    -   (b) A lossy quantization is performed using a quantization        matrix to reduce the precision of the coefficients.    -   (c) The zero values are encoded in a zig-zag sequence (see        Nelson, pp. 341–342).

JPEG can be scaled to perform higher compression ratio by allowing moreloss in the quantization stage of the compression. However this lossresults in certain blocks of the image being compressed such that areasof the image have a blocky appearance and the edges of the 8 by 8 blocksbecome apparent because they no longer match the colors of theiradjacent blocks. Another disadvantage of JPEG is smearing. The trueedges in an image get blurred due to the lossy compression method.

The Moving Pictures Expert Group (MPEG) uses a combination of JPEG basedtechniques combined with forward and reverse temporal differencing. MPEGcompares adjacent frames and for those blocks that are identical tothose in a previous or subsequent frame and only a description of theprevious or subsequent identical block is encoded. MPEG suffers from thesame blocking and smearing problems as JPEG.

These approaches require extensive computer processing and have failedto achieve the necessary compression ratios without unacceptable loss ofimage quality and artificially induced distortion.

QUICKTIME: CINEPAK, SORENSEN, H.263

Apple Computer, Inc. released a component architecture for digital videocompression and decompression, named QuickTime. Any number of methodscan be encoded into a QuickTime compressor/decompressor (codec). Somepopular codes are CinePak, Sorensen, and H.263. CinePak and Sorensenboth require extensive computer processing to prepare a digital videosequence for playback in real time; neither can be used for livecompression. H.263 compresses in real time but does so by sacrificingimage quality resulting in severe blocking and smearing.

FRACTAL AND WAVELET COMPRESSION

Extremely high compression ratios are achievable with fractal andwavelet compression algorithms. These approaches require extensivecomputer processing and generally cannot be completed in real time.

SUMMARY OF THE INVENTION

In accordance with the present invention a method of compression of avideo stream comprises steps of sub-sampling a video frame, determininga code for each pixel, run-length encoding the codes whereby the methodcan be executed in real time and the compressed representation of codessaves substantial space on a storage medium and require substantiallyless time and bandwidth to be transported over a communication link. Thepresent invention includes a corresponding method for decompressing theencoded data.

OBJECTS AND ADVANTAGES

Accordingly, beside the objects and advantages of the method describedin our patent above, some additional objects and advantages of thepresent invention are:

-   -   (a) to provide a method of compressing and decompressing video        signals so that the video information can be transported across        a digital communications channel in real time.    -   (b) to provide a method of compressing and decompressing video        signals such that compression can be accomplished with software        on commercially available computers without the need for        additional hardware for either compression or decompression.    -   (c) to provide a high quality video image without the blocking        and smearing defects associated with prior art lossy methods.    -   (d) to provide a high quality video image that suitable for use        in medical applications.    -   (e) to provide some level of encryption so that images are not        directly viewable from the data as contained in the        transmission.    -   (f) to provide a method of compression of video signals such        that the compressed representation of the video signals is        substantially reduced in size for storage on a storage medium.    -   (g) to enhance electronically generated images by filtering        highs and lows.

DRAWING FIGURES

In the drawings, closely related figures have the same number butdifferent alphabetic suffixes.

FIG. 1 shows the high level steps of compression and decompression of animage.

FIGS. 2A to 2H show alternatives for selecting a pixel value forencoding.

FIG. 3A shows the encode table of the preferred embodiment.

FIG. 3B shows a chart of values corresponding to the sample encode table

FIG. 4A shows a flowchart for the preferred embodiment of thecompression method.

FIG. 4B shows an image and a corresponding stream of pixels.

FIGS. 5A to 5C shows the formats for the run-length encoding.

FIG. 6 shows a series of codes and the resulting encoded stream.

FIG. 7 shows a sample decode table.

FIG. 8 shows an alternate method of selecting a five bit code.

FIG. 9 shows the flow chart for the preferred embodiment of thedecompression method.

FIGS. 10A to 10C show an encryption key, an encryption table and adecryption table.

FIG. 11 illustrates a block diagram of a network for video transmission.

FIG. 12 illustrates a flow chart showing the steps involved in thecompression process within a compressor of an alternate embodiment.

FIG. 13 illustrates a sample data stream representing video pixels and acorresponding compressed data stream.

FIG. 14 illustrates a flow chart showing the steps involved during thedecompression process of an alternate embodiment.

FIG. 15 illustrates an uncompressed data stream, a correspondingcompressed data stream, and a corresponding converted data stream of analternate embodiment.

Reference Numerals in Drawings 100 compression steps 110 sub-samplingstep 120 code lookup step 130 run-length encoding step 140 encoded data150 decompression steps 160 run-length expansion step 170 value lookupstep 180 image reconstitution step 200 32 bit pixel value 202 bluechannel 204 green channel 206 red channel 208 alpha channel 210 24 bitpixel value 212 blue component 214 green component 216 red component 220RGB averaging diagram 222 blue value 224 green value 226 red value 228averaged value 230 blue selection diagram 232 blue instance 234 greeninstance 236 red instance 240 selected blue value 250 green selectiondiagram 260 selected green value 270 red selection diagram 280 selectedred value 290 grayscale pixel 292 grayscale blue 294 grayscale green 296grayscale red 298 selected grayscale value 299 8 bit pixel value 300encode table 310 codes 320 line comments 330 minimum values 340 maximumvalues 360 stepped values 350 chart of values 370 line numbers 400encode flowchart 402 encode entry 403 encode initialization step 404 getpixel step 405 get value step 406 lookup encoded value step 408 compareprevious 410 increment counter step 412 check count overflow 414 newcode step 416 check end of data 418 set done 420 counter overflow step422 check done 428 encode exit 430 image 440 image width 450 imageheight 460 pixel stream 500 code byte 510 flag bit 520 repeat code 530count 550 data code 565 data bit 6 570 data bit 5 575 data bit 4 580data bit 3 585 data bit 2 590 data bit 1 595 data bit 0 610 decimalvalues 620 first value 622 second value 624 third value 626 fourth value628 fifth value 630 sixth value 632 seventh value 640 binary code 650first byte 651 repeat count 652 second byte 653 first code 654 thirdbyte 655 second code 656 fourth byte 657 third code 700 decode table 710alpha values 720 red values 730 green values 740 blue values 800 8 bitpixel 810 pixel bit 7 812 pixel bit 6 814 pixel bit 5 816 pixel bit 4818 pixel bit 3 820 pixel bit 2 822 pixel bit 1 824 pixel bit 0 830 5bit sample 832 sample bit 4 834 sample bit 3 836 sample bit 2 838 samplebit 1 840 sample bit 0 850 ignored bits 860 decompressed pixel 880 3 loworder bits 900 decode entry 901 decode initialize step 902 get code step906 determine type 908 decode lookup step 909 check zero count 910 placepixel step 912 assign counter step 914 reset counter step 916 checklength 918 decode exit 1000 encryption key 1010 encryption table 1020decryption table

TERMINOLOGY CORRELATION

Different terminology was used in the specification of application Ser.No. 09/312,922, portions of which are now included in thisspecification. The two specifications were written by two differentauthors who described distinct embodiments of the subject invention withtwo distinct sets of terminology. The following table provides a partialcorrelation between the two sets of terminology. Note that thiscorrelation of terms does not necessarily mean the term are equivalent.This high level correlation is provided to aid in understandingsimilarities and differences between the two specifications. Also notethat the same term used in this specification in the field of“compression and decompression of video images” is likely to havedifferent meaning in the Ser. No. 09/312,922 specification which waswritten in the field of “video communications systems” and “medicaldevices”. For example in the field of compression the term “image”generally refers to a still image or a single frame of a video, but inthe medical device field the term “image” often refers to the collectionof all the frames in a video. Thus the terms themselves should beunderstood based on the respective original specification. The legalpresumption that terms in related applications by the same inventorshave the same meaning does not apply in this case.

Terms Used In Terms Used in This Application Application 09/312,922 140encoded data stream of compressed data 212 blue component blue scalevalue 214 green component green scale value 216 red component red scalevalue 300 encode table, encodePallet encodeTable decodePalletdecodeTable 310 codes compression lookup table 310 code line number 320line comments documentation 320 350 chart of values lookup table 350 370line numbers line number (column) 430 image video image 400 460 pixelstream stream of pixel data 405 500 code byte data structure 500 510flag bit identification bit 510 520 repeat code repeat data structure525 530 count repeat value 530 count repeat counter value 530 countremaining bits 510 550 data code line number data structure 550 610decimal values uncompressed data stream 1000 640 binary code compresseddata stream 1020 700 decode table decompression lookup table 700 720 redvalues red scale illumination intensity value 710 730 green values greenscale illumination intensity value 720 740 blue values blue scaleillumination intensity value 730

DESCRIPTION OF THE INVENTION FIG. 1—Compression and Decompression Steps

FIG. 1 illustrates a sequence of compression steps 100 and a sequence ofdecompression steps 150 of the present invention. The compression steps100 comprise a sub-sampling step 110, a code lookup step 120 and arun-length encoding step 130. After completion of the compression steps100, a stream of encoded data 140 is output to either a storage mediumor a transmission channel. The decompression steps 150 comprise arun-length expansion step 160 wherein the stream of encoded data 140 isprocessed, a value lookup step 170 and an image reconstitution step 180.

FIGS. 2A to 2H Selecting Pixel Values for Encoding

FIGS. 2A to 2G illustrate alternatives for selecting a pixel value forencoding. The sub-sampling step 110 (FIG. 1) includes sub-sampling of an8 bit pixel value to obtain a value for use in the subsequent codelookup step 120 (FIG. 1).

Video digitizing hardware typical has the options of storing the pixelvalues as a 32 bit pixel value 200 or a 24 bit pixel value 210, shown inFIG. 2A and FIG. 2B, respectively. The 32 bit pixel value 200 iscomposed of a blue channel 202, a green channel 204, a red channel 206,and an alpha channel 208. Each channel contains of 8 bits and canrepresent 256 saturation levels for the particular color channel. Foreach channel the saturation intensity value of zero represents the fullyoff state, and the saturation intensity value of “255” represents thefully on state. The 24 bit pixel value 210 is composed of a bluecomponent 212, a green component 214, and a red component 216. There isno component for the alpha channel in the 24 bit pixel value 210.Regardless of the structure, the blue channel 202 is equivalent to theblue component 212, the green channel 204 is equivalent to the greencomponent 214, and the red channel 206 is equivalent to the redcomponent 216.

In the present invention, the 32 bit pixel value 200 alternative ispreferred due to the consistent alignment of 32 bit values in mostcomputer memories; however for simplicity of illustration the alphachannel 208 will be omitted in FIGS. 2C to 2G.

If the video signal is digitized in color, the three color componentsmay have different values. For example in FIG. 2C, a RGB averagingdiagram 220 illustrates a blue value 222 of 35 decimal, a green value224 of 15, and a red value 226 of 10. One alternative is to sub samplefrom 24 bits to 8 bits by averaging the three color values to obtain anaveraged value 228 that, in this example, has the value of 20.(10+15+35)/3=20

FIG. 2D illustrates another alternative for selecting an 8 bit value ina blue selection diagram 230. In this example, a blue instance 232 hasthe value of 35, a green instance 234 has the value of 15, and a redinstance 236 has the value of 10. In this alternative the blue instance232 is always selected as a selected blue value 240.

FIG. 2E illustrates another alternative for selecting an 8 bit value ina green selection diagram 250. In this alternative the green instance234 is always selected as a selected green value 260.

FIG. 2F illustrates another alternative for selecting an 8 bit value ina red selection diagram 270. In this alternative the red instance 236 isalways selected as a selected red value 280.

If the video signal being digitized is grayscale, the three colorcomponents will have the same values. For example, in FIG. 2G, agrayscale pixel 290 comprises a grayscale blue 292 with a value ofdecimal 40, a grayscale green 294 with a value of 40, and a grayscalered with a value of 40. Because the values are all the same, it makes nodifference which grayscale color component is selected, a selectedgrayscale value 298 will have the value of 40 in this example.

The preferred embodiment of this invention uses the low order byte ofthe pixel value, which is typically the blue component as shown in FIG.2D.

FIG. 2H illustrates an 8 bit pixel value 299 which is selected by one ofthe alternatives described above. The 8 bit pixel value 299 isequivalent to items referenced by numerals 228, 240, 260, 280, or 298.This reduction of the 32 bit pixel value 200 or the 24 bit pixel value210 contributes a reduction in data size of 4:1 to 3:1, respectively.This reduction recognizes that for some images, such as medical imagesor grayscale images, no relevant information is lost.

FIG. 3A—Encode Table

FIG. 3A illustrates an encode table 300 of the preferred embodiment ofthe present invention. The encode table 300 may be implemented in the Cprogramming language, as shown, and is an array of 256 bytes. Thesebytes are the codes 310. Each line of the array elements is documentedwith one of a series of line comments 320. The line comments 320 containa column of minimum values 330, a column of maximum values 340, and acolumn of stepped values 360. The first column of encode table 300 is acolumn of line numbers 370. The encode table is arranged such that eachline contains codes 310 that have a value equal to its line number.

The encode table 300 reduces the 8 bit value 299 to a 5 bit code. Thisreduction recognizes that for some images, such as medical images, norelevant information was lost. This reduction also eliminates noise fromthe video signal and thereby increases the efficiency of the run-lengthencoding step 130 (FIG. 1).

Using alternate terminology, FIG. 3A illustrates software code which ispreferably utilized to perform compression of a stream of video datawithin the compressor (not shown) within the transmitter (FIG. 11). Thissoftware code includes a lookup table 310 with storage locationsrepresenting illumination intensity values from 0 to 255. Eachrepresentative storage location includes a line number from 0 to 31,which is indexed to a decompression lookup table. The compression lookuptable 310 allows an eight-bit entry representing values from 0 to 255 tobe compressed into a five-bit value. When provided with an illuminationintensity value, the line number stored in the corresponding locationwithin the compression lookup table 310 is read and provided as thecompressed five bit illumination intensity value.

Documentation 320 is utilized to more clearly illustrate the function ofeach line contained within the compression lookup table 310. If theillumination intensity value is two (on a scale of 0 to 255), the linenumber zero stored at the storage location corresponding to thisillumination intensity value is read from the compression lookup table310. As can be seen from the compression lookup table 310, anyillumination intensity value between zero to four has a correspondingfive-bit line number of zero (on a scale of 0 to 31). In a furtherexample, if the illumination intensity value is eighty, the line numberten scored at the storage location corresponding to this illuminationintensity value is read from the compression lookup table 310. Insteadof transmitting an eight-bit value of 0 to 255, which corresponds to anillumination intensity value of a pixel, the compression lookup table310 is utilized to compress the eight-bit illumination intensity valueinto a corresponding five-bit line number value between 0 and 31.

This compression process is preferably optimized to compress datarepresenting a stream of video images which originates from the videosource 1101 (FIG. 11) and is received by the transmitter 1201 (FIG. 11).In practice, this data representing the stream of video images istransmitted in terms of a stream of pixel data. A predetermined numberof pixels represent each video image. For each pixel, the illuminationintensity value of zero represents a fully off state, and theillumination intensity value of “255” represents a fully on state.

FIG. 3B—Chart of Values

FIG. 3B, a chart of values 350, enumerates the range that the 8 bitpixel value 299 can have and the respective placement of each value inthe encode table 300. The first column of the chart enumerates the linenumbers 370. Column A contains the minimum values 330 for each line.Each row of the chart has from four to nine sequential entries. The lastcolumn of the chart, column J, contains the stepped values (360) thatare used in the value lookup step 170 (FIG. 1).

Using alternate terminology, FIG. 3B illustrates a lookup table 350.This look-up table 350 shows a logical representation of the compressionprocess according to the compression lookup table 310 shown in FIG. 3A,for illustrative purposes only. The lookup table 350 classifies aneight-bit illumination intensity value for a pixel into an appropriatelevel within a reduced level index representing the five-bit linenumber. There are preferably 32 levels within this reduced level index,from 0 to 31, which are represented by the rows 0 to 31 on the left ofthe table 350. Each line number corresponds with one of the levelswithin the reduced level index. The lookup table 350 also includes 10columns, which are represented by 330 and 360. The entries withincolumns 330 represent the illumination intensity value for the pixel andcorresponds to the storage locations within the lookup table 350. Eachof the illumination intensity values is compressed into the line numberof the row on which the illumination intensity value is found within thetable 350.

The entries within column 360 are an average illumination intensitylevel associated with each line number, which will be discussed below inrelation to the decompression lookup table. This average illuminationintensity level falls within a range of a lowest and highestillumination intensity value within the particular row.

As a further example of the pixel data compression technique of thepresent invention utilizing the lookup table 350 when provided withpixel data having an illumination intensity value of 167, the linenumber 20 is provided as the compressed value from the compressionlookup table. Any pixel having an illumination intensity value between162 and 169 corresponds to the line number 20 in the lookup table 350.

Accordingly, for pixels having illumination intensity values between andincluding 162 and 169, the five bit line number 20 is provided as thecompressed value, which is either stored by the recorded video device1104 (FIG. 11) or transmitted by the transmitter 1103 to one or more ofthe receivers 1106.

FIG. 4A—Encode Flowchart

FIG. 4A illustrates the encode flowchart 400 which represents thedetails of the preferred embodiment of the code lookup step 120 (FIG. 1)and the run-length encoding step 130 (FIG. 1) for the present invention.

The encoding begins at an encode entry 402. In a encode initializationstep 403, a prior value P is set to a known value, preferably decimal“255” or hexadecimal 0×FF, a repeat count C is set to zero, an encodedlength L is set to 0, and a completion flag “Done” is set to a logicalvalue of false. Next, a get pixel step 404 obtains a pixel from theimage being encoded. At a get value step 405, a value V is set to the 8it pixel 299 as derived from the pixel using one of the methods shown inFIGS. 2C to 2G, preferably the fastest as explained above. At a lookupencoded value step 406, an encoded value E is set to the value of one ofthe codes 310 (FIG. 3) of the encode table 300 as indexed by V. Next, acompare previous 408 decision is made by comparing the values of E andP. If the values are the same, a increment counter step 410 is executedand flow continues to the get pixel step 404 that obtains the next pixelfrom the image.

If the encode value E does not match the prior value P, then a checkcount overflow 412 decision is made. If the counter C is less than orequal to 128, then a new code step 414 is executed, otherwise a counteroverflow step 420 is executed.

At step 414, the counter C is bit-wise AND-ed with hexadecimal 0×8 whichsets the high order bit to a binary value of 1 and is placed in theencoded data 140 buffer A at the next available location as indexed bythe encoded length L. Then, continuing inside flowchart steps 414, L isincremented, the prior value P is placed in the encoded data 140 bufferA, L is incremented, the repeat count C is set to 1 and the prior valueP is set to the encode value E. After step 414, a check end of datadecision is made by checking to see if there are any more pixels in theimage and if not if the last value is has been processed. Because thismethod utilizes a read ahead technique, step 414 must be execute onemore time after the end of data is reached to process the lastrun-length. If there is more data in the image, flow continues to acheck of the completion flag “Done” at step 422. If the check indicatesthat the process is not completed, flow continues to step 404.

If the end of data is reached but the completion flag “Done” is stillfalse, flow continues to a set done step 418. At step 418, thecompletion flag “Done” is set to logical true, and flow continues todecision 412 where the last run-length will be output and flow willeventually exit through step 414, decision 416, decision 422, and thenterminate at encode exit 428.

It is possible for the repeat count C to become larger than 128requiring more bits than allocated by this method. This situation ishandled by making the check count overflow 412 decision and executingthe counter overflow step 420. At step 420, the value hexadecimal 0×80is placed in the encoded data 140 buffer A at the next availablelocation as indexed by the encoded length L. Then, continuing insideflowchart step 420, L is incremented, the prior value P is placed in theencoded data 140 buffer A, L is incremented, the repeat count C isdecrement by 128. After step 420, flows continues to the check countoverflow 412 decision. Thus when the encode value E repeats more that128 times, multiple sets of repeat counts and encoded values are outputto the encoded data 140 buffer.

This entire process is repeated for each image or video frame and theencoded length L is transmitted with the encoded data associated witheach frame. The encoded length varies from frame to frame depending onthe content of the image being encoded.

FIG. 4B—Image and Pixel Stream

FIG. 4B illustrates an image and its corresponding stream of pixels. Arectangular image 430 is composed of rows and columns of pixels. Theimage 430 has a width 440 and a height 450, both measured in pixels.Pixels in a row are accessed from left to right. Rows are accessed fromtop to bottom. Some pixels in the image are labeled from A to Z. Pixel Ais the first pixel and pixel Z is the last pixel. Scanning left to rightand top to bottom will produce a pixel stream 460. In the pixel stream460, pixels A and B are adjacent. Also pixels N and O are adjacent eventhough they appear on different rows in the image. If adjacent pixelshave the same code the process in FIG. 4A will consider them in the samerun.

Because the video signal being digitized is analog there will be someloss of information in the analog to digital conversion. The videodigitizing hardware can be configured to sample the analog data into theimage 430 with almost any width 440 and any height 450. The presentinvention achieves most of its effective compression by sub-sampling thedata image with the width 440 value less than the conventional 640 andthe height 450 value less than the convention 480. The preferredembodiment of the invention for use in a medical application with T1Internet transmission bandwidth is to sample at 320 by 240. However, asampling resolution of 80 by 60 may be suitable for some videoapplication.

Using alternative terminology, FIG. 4B illustrates a representativevideo image 430 and a corresponding stream of pixel data 460representing the video image 430. The pixel data is transmitted in anorder representing pixel from left to right on each horizontal line,successively, from top to bottom of the video image. As an example,pixels “C” and “D” are considered consecutive pixels within the streamof pixels 460.

FIGS. 5A to 5C—Run-Length Encoding Formats

FIGS. 5A to 5C show the formats for the run-length encoding. FIG. 5Ashows a code byte 500, with its high order bit designated as a flag bit510. Using alternate terminology, FIG. 5A illustrates a data structure500 having 8 bits of storage. An identification bit 510 is preferably aleading bit within the data structure 500. This identification bit 510signals whether the particular data structure contains a line numberrepresenting the illumination intensity level or a repeat valuerepresenting a number of times to repeat an illumination intensity valueof a prior pixel. The data structure 500 is used to carry bothcompressed line number values and the repeat value for compressedstrings of similar pixels.

FIG. 5B shows a repeat code 520 comprising a Boolean value one in itsflag bit 510 and a 7 bit count 530 in the remaining 7 low order bits.The seven bits count 530 can represent 128 values with a zerorepresenting “128” and 1 through 127 being their own value.

Using alternate terminology for an alternate embodiment, FIG. 5Billustrates a data structure 520 used to transmit the repeat value,which has a specific configuration of the data structure 500 (FIG. 5A).To signal that this data structure 520 is transmitting a repeat value,the identification bit 510 includes a value corresponding to a logicalone. The number of times to repeat is preferably stored in the sevenremaining bits 530. By storing a logical one in the identification bit510, the decompressor within the receiver 1106 (FIG. 11) is instructedin an alternate embodiment while decoding to repeat the line number ofthe previous pixel a number of times corresponding to the seven bitrepeat value. In this embodiment, the repeat counter value is limited toa value of 127 which is the maximum number capable of being expressed byseven bits. Alternatively, the repeat counter value can be representedby any appropriate number of bits.

FIG. 5B shows a data code 550 comprising:

1. a Boolean value zero in its flag bit 510

2. two unused data bits: data bit 6 reference by 565 and data bit 5reference by 570, and

3. five bits, data bits 4 to 0, referenced by 575, 580, 585, 590, and595, respectively.

The five bits hold a 5 bit code selected from the codes 310 (FIG. 3A) inthe encode table 300 (FIG. 3A).

Using alternative terminology, FIG. 5C illustrates a data structure 550used to transmit a line number, which has a specific configuration ofthe data structure 500 (FIG. 5A). To signal that this data structure 550is transmitting a compressed line number, representing an illuminationintensity value of a pixel, the identification bit 510 includes a valuecorresponding to a logical zero. The data structure 550 is configured totransmit the line number that represents the illumination intensitylevel of the pixel. Preferably the bits 565 and 570 are unused. The bits575–595 represent the five-bit line number corresponding to theillumination intensity value from the compression lookup table 310 (FIG.3A). By setting the identification bit 510 to a logical zero, thedecompressor within the receiver 1106 (FIG. 11) recognizes thatinformation held in the five bits 575–595 represents the line numbercorresponding to the illumination intensity value of a pixel in the datastream.

The preferred embodiment of this invention uses the high order bit ofthe code byte 500 as the flag bit (or identification bit) 510, becauseit results in the faster execution of the process. However, any bitcould have been designated as the flag bit 510 with the same logicalresult.

FIG. 6—Encoded Data Stream

FIG. 6 shows a series of decimal values 610 comprising a first value 620equal to decimal 0, a second value 622 equal to 0, a third value 624equal to 0, a fourth value 626 equal to 0, a fifth value 628 equal to 0,a sixth value 630 equal to 2, and a seventh value 632 equal to 10. Afterthe run-length encoding step 130 (FIG. 1), the corresponding encodeddata 140 (FIG. 1) would be compressed down to four bytes of binary code640 comprising a first byte 650 containing a repeat count 651, a secondbyte 652 containing a first code 653, a third byte 654 containing asecond code 655, and a fourth byte 656 containing a third code 657. Therepeat count 651 has a binary value of “0000101” which equals decimalfive representing the run-length of the repeating value in the firstfive of the decimal values 610. The first code 652 has a binary value of“00000” which equals the repeated decimal value zero. The second code655 has a binary value of “00010” which equals the non-repeated decimalvalue two. The third code 657 has a binary value of “01010” which equalsthe non-repeated decimal value ten.

FIG. 7—Decode Table

FIG. 7 illustrates a decode table 700 of the preferred embodiment of thepresent invention. The decode table 700 may be implemented in the Cprogramming language, as shown, or any programming language, and is anarray of 32 element with each element being a 32 bit pixel value 200(FIG. 2A). The decode table is comprised of a column of alpha values710, a column of red values 720, and a column of green values 730, and acolumn of blue values 740, where the alpha values 710 are shifted by 24bits, the red values 720 are shifted by 16 bits, and the green values730 are shifted by 8 bits leaving the blue values 740 in place. The linein the decode table 700 contains one element. Each element comprising:

1. the alpha channel 208 (FIG. 2A) with full intensity represented byhexadecimal 0×FF

2. the red channel 206 (FIG. 2A)

3. the green channel 204 (FIG. 2A)

4. the blue channel 202 (FIG. 2A)

where the values of the three color channels are equal to thecorresponding stepped values 360 (FIGS. 3A and 3B) associated with eachline of the encode table 300 (FIG. 3A).

Although each element is documented as an expression composed of variousbit shift and bit-wise OR operations, the expression is evaluated by thecompiler when the program is compiled so that each element of the decodetable 700 is a 32 bit pixel value 200 (FIG. 3A) ready for directplacement in the decompressed image.

In the preferred embodiment of this invention the 32 bit pixel value 200(FIG. 2A) is used; however other embodiments use the 24 bit pixel value210 (FIG. 2B) or other pixel sizes known in the art. Embodiments ofother common pixel depths of 16 bit, 15 bit, 8 bit, 4 bit, 3 bit or 1bit could be used without limiting the scope of this invention. Ofcourse any source resolution less than or equal to five bits wouldbenefit from a modified and shortened encode and encode table or couldbe encoded by shifting bits as explained below.

Using alternate terminology, FIG. 7 illustrates software code utilizedto decompress a compressed stream of data. This software code includes adecompression lookup table 700 which is utilized within the decompressorwithin the receiver 1106 (FIG. 11). The decompression lookup table 700is indexed to provide an output average illumination intensity valuecorresponding to the received line number from the compression lookuptable 310. In an alternate embodiment, this decompression lookup table700 transforms the line number representing the illumination intensityfor the stream of pixels which was previously processed by thecompressor within the transmitter 1103 (FIG. 11) back into a convertedillumination intensity data stream having thirty-two levels ofillumination intensity.

Similar to the compression lookup table 310 (FIG. 3A), the decompressionlookup table 700 utilizes thirty-two levels wherein each levelrepresents the particular line number. For each received line number,the decompression lookup table 700 provides an output averageillumination intensity value for a red scale illumination intensityvalue 720, a green scale illumination intensity value 703, and a bluescale illumination intensity value 740.

Preferably, these output average illumination intensity values are allequal, thereby providing a gray scale image.

FIG. 8—Alternate Code Selection

FIG. 8 illustrates an alternate embodiment of this invention wheretables are not used for encoding and decoding. Instead, the high order 5bits 810–818 of an 8 bit pixel 800 are shifted to the right by 3 bitpositions to form a five bit sample 830. The upper 3 bits of 830 areignored bits 850. This shifting to obtain a five bit code replaces steps405 and 406 of the flowchart in FIG. 4A. The same run-length encodingmethod is used. During decompression the five bit sample 830 is shiftedto the left by 3 bit positions to form a decompressed pixel 860, wherethe 3 low order bits 880 are filled with zero binary values.

FIG. 9—Decode Flowchart

FIG. 9 illustrates the decode flowchart which presents the details ofthe preferred embodiment of the value lookup step 170 (FIG. 1) and theimage reconstitution step 180 (FIG. 1).

The decoding begins at a decode entry 900. In a decode initializationstep 901, a repeat counter C is set to one, an encoded length L is setto the value obtained with the encoded data 140 (FIG. 1), and an index Iis set to 0. Next, a get code step 902 obtains a signed byte X from theencoded data 140 (FIG. 1) array A. A determine type 906 decision checksto see if the signed byte X is less than 0.

If the signed byte X is less than zero, it is because the high orderbit, the flag bit 510 (FIG. 5A) is set to binary value 1, as in FIG. 5B,indicating that the byte X is a repeat code 520. Flow goes to assigncounter step 912 where the count 530 (FIG. 5B) is extracted from X andplaced in the repeat counter C and the next code is accessed byincrementing the index I and returning to the get code step 902.

If the signed byte X is greater than or equal to zero, it is because theflag bit 510 (FIG. 5A) is set to binary 0, as in FIG. 5C, indicatingthat the byte X is a data code 550. Flow goes to a decode lookup step908 where the value of byte X is used to index into the decode table 700(FIG. 7) to obtain a pixel value V. Flow continues to a check zero count909 decision.

The 909 decision always fails the first time ensuring that a place pixelstep 910 is executed. The place pixel step 910 places the pixel value Vin the next location of the decompressed image and decrements the repeatcounter C and returns to the 909 decision. The pixel value V is placedrepeatedly until C decrements to zero. Then the 909 decision branchesflow to a reset counter step 914. At step 914 the repeat counter isreset to 1 and the index is incremented to select the next code.

Flow continues to the check length 916 decision where the index I iscompared to the encoded length L to determine if there are more codes tobe processed. If I is less than L flow returns to step 902, otherwisethe decode process terminates at a decode exit 918.

The entire decode process is repeated for each frame image.

FIGS. 10A to 10C—Encrytpion Key, Encryption Table, and Decryption Table

FIG. 10A shows an encryption key 1000. The first column shows theoriginal code. The second column shows the corresponding cipher code.

FIG. 10B shows an encryption table 1010, and FIG. 10C shows a decryptiontable 1020. The encryption table 1010 has the same format as thestandard encode table 300 (FIG. 3A), and the decryption table 1020 hasthe same format as the decode table 700 (FIG. 7). However the entries inboth tables are rearranged such that the direct correlation between theintensity level and the position in the table is broken. When theseversions of the tables are used, the encode and decode processes andtheir speed of execution are substantially the same but the encoded data140 (FIG. 1) becomes a cipher and has a higher level of security. Itshould be recognized by one with ordinarily skill in the art that thereare other embodiments of the present invention with differentencryption/decryption table rearrangements.

FIG. 11—Video Transmission System

FIG. 11 illustrates a video system 1100 according to the presentinvention for transmitting video images from one location to another.The video system 1100 preferably includes a video source 1101, a videocassette recorder 1102, a transmitter 1103, a recorded video device1104, a computer network 1105, a plurality of receivers 1106, and datalinks 1110, 1115, 1120, and 1125. Preferably, the video source 1101includes the video cassette recorder 1102 and is coupled to thetransmitter 1103 via the data link 1110. The transmitter 1103 is alsopreferably coupled to the recorded video device 1104 and the computernetwork 1105 via the data links 1115 and 1120, respectively.

Preferably, the plurality of receivers 1106 are coupled to the computernetwork 1105 via the data links 1125. Each of the plurality of receivers1106 is preferably a computer system having a display, centralprocessing unit, and input device. The data links 1125 preferably linkeach of the plurality of receivers 1106 to the computer network 1105.The data links 1125 include any appropriate connection to the computernetwork 1105 including T1 communication lines, DSL links, cellularlinks, microwave transmission, land lines, twisted pair cable, and thelike. The video system 1100 shown in FIG. 11 is merely illustrative andis only meant to show a preferred embodiment of the present invention.

In alternate embodiments, additional transmitters, video sources, andreceivers could be included without departing from the spirit and scopeof the video system 1100.

Additionally, in an alternate embodiment, the transmitter 1103 isincluded within the computer network 1105 and functions as a serverwithin the computer network 1105.

The recorded video device 1104 is preferably coupled to the transmitter1103 via the data link 1115. Preferably, the recorded video device 1104stores video images received by the transmitter 1103 for playback at alater time.

The transmitter 1103 preferably controls the flow of video from both thevideo source 1101 and the recorded video component 1104 over thecomputer network 1105 to any number of the plurality of receivers 1106.Preferably, the transmitter 1103 compresses the video images prior totransmission to one of the plurality of receivers 1106, using anembodiment of the compression method described herein.

In the video system 1100, the computer network 1105 is preferably anInternet Protocol network. In alternate embodiments, the computernetwork 1105 is any appropriate data network. The computer network 1105is configured to transmit information between the plurality of receivers1106 and the transmitter 1103 via the data links 1125 and 1120,respectively.

The plurality of receivers 1106 are preferably configured to selectivelyreceive a stream of video images from the transmitter 1103 via the datalink 1120, the computer network 1105, and the appropriate data link1125. For example, at least one of the plurality of receivers 1106 isprogrammed to receive the stream of video images from the transmitter1103. Accordingly, only the selected ones of the plurality of receivers1106 are capable of receiving the stream of video images from thetransmitter 1103. In addition to receiving the stream of video images,the selected ones of the plurality of receivers 1106 are also capable oftransmitting instructions to the transmitter 1103 via the data link1125, the computer network 1105, and the data link 1120.

Preferably, one of the receivers 1106 decompresses the video images uponreceipt using an embodiment of the decompression method of describedherein.

FIG. 12—Alternate Compression Flow Chart

FIG. 12 shows a flow chart that illustrates an alternate embodiment ofthe compression process utilized by the transmitter when compressing astream of video data. Using alternate terminology, this compressionprocess begins at the start step 1202, clearing the buffer (not shown)and resetting the repeat counter value to zero. At the step 1204, anillumination intensity value representing a current pixel is received.Next, at the step 1206, a current line from the lookup table 310 (FIG.3A) is obtained for the pixel data corresponding to the currentillumination intensity value for the pixel. At the step 1208, it isdetermined whether the current line number for the pixel data is thesame as the previous line number. The previous line number is preferablystored in the buffer. If the previous line number is not stored in thebuffer, then the current line number and the previous line number cannotbe the same. If the line number is the same as the previous line number,the repeat counter value is incremented by one, at the step 1210. It isthen determined whether the repeat counter value is equal to a value of127, at the step 1212. If the repeat counter value is equal to a valueof 127, then, at the step 1214, the repeat counter value is transmittedout of the transmitter within a data structure that is similar to thedata structure 520 (FIG. 5B). Additionally in the step 1214, the repeatcounter value is reset to a value of zero after being transmitted in thedata structure. If the repeat counter is not equal to the value of 127,the process then proceeds directly to the step 1216.

Returning back to the step 1208, if the current line number is not thesame as the previous line number, then it is determined whether therepeat counter value is equal to a value of zero, in the step 1220. Ifit is determined at the step 1220, that the repeat counter value is notequal to the value of zero, then at the step 1222, the repeat countervalue is transmitted out of the compressor and into the buffer within adata structure that is similar to the data structure 520 (FIG. 5B).Additionally, at the step 1222, the repeat counter value is reset to avalue of zero after being transmitted in the data structure. If it isdetermined at the step 1220, that the repeat counter value is equal tothe value of zero, or after the step 1222 is completed, then the linenumber representing the current illumination intensity value istransmitted out of the compressor and into the buffer, at the step 1224,within a data structure that is similar to the data structure 550 (FIG.5C). Additionally, after the current line number is transmitted, thecurrent line number is stored in the buffer as the previous line number,at the step 1224. After the step 1224 is completed, the process proceedsto the step 1216.

At the step 1216, it is determined whether there is any additional pixeldata corresponding to additional pixels. If there is additional pixeldata, then the compression process loops back to the step 1204 toreceive and process the data representing the next pixel. If there is noadditional pixel data, then the process proceeds to the step 1218. Atthe step 1218, it is determined whether the repeat counter value isequal to a value of zero.

If the repeat counter value is equal to the value of zero, then theprocess proceeds to the ending step 1228. If the repeat counter value isnot equal to the value of zero, then, at the step 1226, the repeatcounter value is transmitted out of the compressor and into the bufferwithin a data structure that is similar to the data structure 520 (FIG.5B). Additionally in the step 1226, the repeat counter value is reset toa value of zero after being transmitted in the data structure. After thestep 1226, then the process proceeds to the ending step 1228.

FIG. 13—Alternate Encoded Data Stream

FIG. 13 illustrates a sample uncompressed illumination intensity datastream 1310 including data blocks 1320, 1322, 1324, 1326, 1328, 1330,and 1332. This example uses the same data as shown in FIG. 6. Acomparison with FIG. 6 while highlight the differences between the flowchart in FIG. 4A and FIG. 12.

Using alternate terminology, each block includes pixel data representingan illumination intensity value of a corresponding pixel in thisuncompressed data stream 1310 (same as 610). Preferably, thisillumination intensity level is the blue scale value for the particualrrepresented pixel. For example, after the step 1206 (FIG. 12) ofobtaining a line number for each of the data blocks, the blocks1320–1328 have a line number value of zero; the block 1330 has a linenumber value of two; and the block 1332 has a line number value of ten.A compressed illumination intensity data stream 1340 includes datastructures 1350, 1352, 1354, and 1356. The compressed data stream 1340represents the uncompressed data stream 1310 with four data structures.Similar to the illumination intensity data structure 550 (FIG. 5C), thedata structures 1350, 1354, and 1356 represent the illuminationintensity value of the pixels associated with the data blocks 1320,1330, and 1332, respectively. A segment 1351 of the data structure 1350contains a five-bit line number having a value of zero. Similarly, thesegments 1355 and 1357 contain five-bit line numbers having values oftwo and ten, respectively. Similar to the repeat data structure 520(FIG. 5B), the data structure 1352 represents the illuminationintensities of the pixels associated with the data blocks 1322, 1324,1326, and 1328. A segment 1353 stores the seven bit repeat counter valueof four which is the number of times the line number of the prior pixel1320 is repeated.

FIG. 14—Alternate Decompression Flow Chart

FIG. 14 illustrates a flow chart which shows an alternate decompressionprocess utilized by the decompressor within the receiver 1106 todecompress a compressed stream of data.

Using alternate terminology, this decompression process begins at astart step 1400 and proceeds to the step 1402. At the step 1402, astream of compressed data that was compressed by the compressor andincludes data representing the illumination intensity of a plurality ofpixels waits to be received. The stream of compressed data contains aplurality of data structures which resemble the data structure 500 (FIG.5A). At the step 1402, the next data structure in the stream ofcompressed data is received as a present data structure. Next, at thestep 1404, the identification bit within the present data structurereceived by the step 1402 is detected. At the step 1406, it isdetermined if the identification bit which was detected at the step 1404has a value of logical zero or logical one. If the identification bithas a value of logical one, then the present data structure contains arepeat counter value and is decoded at the step 1412. If theidentification bit has a value of logical zero, then the present datastructure contains a line number and is decoded at the step 1408.

At the step 1412, the repeat counter value is read from the present datastructure.

Recall that the repeat counter values stores the number of times torepeat the line number associated with the illumination intensity valuesof the prior pixel. Next, at the step 1414, a particular number ofpixels corresponding to a number stored as the repeat counter value, isgenerated with the illumination intensity values of the prior pixel. Theillumination intensity value of the prior pixel is stored in the bufferwithin the decompressor. For example, if the repeat counter value iffive, then five pixels are generated with the illumination intensityvalues of the prior pixel at the step 1414.

At the step 1408, the line number is read from the present datastructure. The line number corresponds to a row within the decompressionlookup table 700 (FIG. 7) which includes the illumination intensityvalues for the pixel. Next, at the step 1410, a pixel is generatedhaving illumination intensity value which correspond to the line numberread from the step 1408. Additionally, the illumination intensity valuesare also stored in the buffer within the decompressor. For example, ifthe line number within the present data structure has a value of two,then according to the decompression lookup table 700 (FIG. 7), theillumination intensity values for the red, green, and blue values of thepixel are sixteen.

After the illumination intensity values are determined at the step 1410or the step 1414, it is determined, at the step 1416, if there areadditional data structures within the compressed stream of datacurrently being received. If there are additional data structures, thenthis process loops back to the step 1402 where the next data structureis received, and the process begins again. If there are no additionaldata structures, then this process ends at the step 1418.

FIG. 15—Example of Compression and Decompression Using the AlternateMethods

In FIG. 15, sample data stream illustrating the compression and thedecompression process of the alternate embodiment are shown. The sampledata include an uncompressed data steam 1500, a compressed data stream1520, and a decompressed data stream 1550. The uncompressed data stream1500 includes seven pixel data blocks 1502 through 1514 wherein each ofthese pixel data blocks represent the illumination intensity of theparticular pixel. The compressed data stream 1520 include four datablocks 1522–1528 which are generated by the compressor and represent theuncompressed data stream 1500. The decompressed data stream 1550 isgenerated from the decompressor and includes seven pixel data blocks1552–1564 each representing the average illumination intensity value ofthe particular pixel.

ADVANTAGES Filtering and Image Enhancement

The stepped values 360 (FIG. 3A) are a significant discovery of thepresent invention. The use of these specific values results in highquality decompressed images when the original image is generated by anelectronic sensing device such as an ultrasound machine. The encodetable 300 is arranged such that the spikes in the video signal arefiltered in the high and low end, line numbers 31 and 0, respectively.The remaining values are distributed more evenly with larger ranges atline 3, 7, 15, 19, 23, and 27.

By altering the contents of the encode table 300 and the decode table700 various filters can be implemented to enhance the image quality. Ahigh or low noise filter can be beneficial when the image is generatedby an imaging technology such as radar, ultrasound, x-ray, magneticresonance, or similar technology. Variations in the encode and decodetable can be made to enhance the perceived quality of the decompressedimage. Therefore, altering the contents, shape, or size of the encodetable 300 and the decode table 700 is anticipated by this invention andspecific values in the tables should not be construed as limiting thescope of this invention.

Execution Speed

The preferred embodiment of this invention use a number of techniques toreduce the time required to compress and decompress the data.

The methods require only a single sequential pass through the data. Boththe compression steps 100 and the decompression steps 150 access a pixelonce and perform all calculations.

When selecting the 8 bit pixel value 299, the preferred embodimentselects the low order bits from the 32 bit pixel value 200 or the 24 bitpixel value 210 so that an additional shift operation is avoided.

The encoded table 300 is a fast and efficient way to convert the 8 bitpixel value 299 into one of the 5 bit codes 310.

The decode table 700 contains 32 entries each comprised of the 32 bitpixel value 200 that are ready for placement in the decompressed image.Although each element is documented as an expression composed of variousbit shift and bit-wise OR operations, the expression may also beevaluated by a compiler when the program is compiled so that eachelement of the decode table 700 becomes a 32 bit pixel value 200.

General Purpose

Although the preferred embodiment of the present invention is tuned tothe characteristics of a medical image, its lossless compression of thesampled data results in high quality video streams that have generalpurpose application in a number of areas including, without limitation,video conferencing, surveillance, manufacturing, and rich mediaadvertising.

Lossless Nature/No Artifacts

Once the analog signal is sub-sampled and filtered to select a five bitcode value which eliminates some of the real world defects, the methodsof the present invention compress and decompress the data with noirreversible data loss. Unlike JPEG and MPEG, the decompressed imagenever suffers from artificially induced blocking or smearing or otherartifacts that are result of the lossy compression algorithm itself. Asa result even a small sub-sample of the image remains clear and true tothe perceive quality of the original image.

CONCLUSION, RAMIFICATION, AND SCOPE

Accordingly, the reader will see that the compression and decompressionsteps of the present invention provides a means of digitally compressinga video signal in real time, communicating the encoded data stream overa transmission channel, and decoding each frame and displaying thedecompressed video frames in real time.

Furthermore, the present invention has additional advantages in that:

1. it provides a means of filtering real world defects from the videoimage and enhancing the image quality;

2. it allows for executing of both the compression and decompressionsteps using software running on commonly available computers withoutspecial compression or decompression hardware;

3. it provides decompressed images that have high spatial quality thatare not distorted by artifacts of the compression algorithms being used;

4. is provides a scalable means of video compression; and

5. it provides a means for reducing the space required in a storagemedium.

Although the descriptions above contain many specifics, these should notbe construed as limiting the scope of the invention but as merelyproviding illustrations of some of the preferred embodiments of thisinvention. For example, stepped values in the encode and decode tablescan be altered and the same relative operation, relative performance,and relative perceived image quality will result. Also, the processescan each be implemented as a hardware apparatus that will improve theperformance significantly.

Thus the scope of the invention should be determined by the appendedclaims and their legal equivalents, and not solely by the examplesgiven.

1. A method of compression of graphic images which make up a videostream, comprising the steps of: (a) selecting an image from saidgraphic images; (b) processing each pixel in a set of pixels from saidimage comprising the steps of: (i) selecting a first number of bits fromeach said pixel wherein each pixel comprises a second number of bits andwhere in said first number of bits is less than said second number ofbits (ii) selecting a code value based on the value of said first numberof bits wherein said code value is directly related to said value ofsaid first number of bits, and wherein the code value is a third numberof bits; (iii) determining if said code value is the same as a previouscode value of an immediately prior pixel; (iv) if the code value is thesame as a said previous code value, incrementing a run-length counterwhich counts the number of matching code values; (v) if the code valueis not the same as said previous code value, placing said previous codevalue and a current value of said run-length counter in an array ofencoded data, wherein said previous code value and said current countervalue comprise an encoded code, and resetting the value of therun-length counter; (c) upon processing the last pixel in said set ofpixels from said image, placing the last previous code value and thelast current value of said run-length counter in said array of encodeddata, whereby said array of encoded data represents said image; (d)outputting said array of encoded data; (e) selecting a subsequent imagefrom said graphic images; (f) repeating steps (b) through (e) for aseries of said subsequent images.
 2. The method of claim 1 wherein saidimage and said subsequent image are from of a set of images that areseparated temporally by a predetermined period of time.
 3. The method ofclaim 2 wherein said the predetermined period of time is less than orequal to 1/15th of a second.
 4. The method of claim 1 wherein said setof pixels is a subset of all the pixels in said image.
 5. The method ofclaim 4 wherein said subset of all the pixels in said image is selectedby selecting every other pixel in every other row of pixels.
 6. Themethod of claim 1 wherein said code value is the same value as saidfirst number of bits wherein said code value directly related to saidvalue of said first number of bits by equivalence.
 7. The method ofclaim 1 wherein said first number of bits is eight, said second numberof bits is greater than eight, and a third number bits is five.
 8. Themethod of claim 1 wherein said code value is obtained from an encodetable.
 9. The method of claim 8 wherein said code value is an encryptedvalue which is not equal to any of the group of: (a) the value of thefirst number of bits selected from of said pixel, (b) the value of thesecond number of bits of said pixel, (c) the value of any third numberof bits selected from of said pixel, whereby the original value of saidpixel is not readily discernable from said code value.
 10. A storagemedium comprising an encoded video signal comprising a series of saidarray of encoded data as claimed in claim 1, wherein at least a portionof said video stream is stored in an encoded format.
 11. The method ofclaim 1 further comprising the decompression steps of: (g) inputtingsaid array of encoded data; (h) processing each said encoded code insaid array, comprising the steps of: i. extracting said code value as adecode value, ii. extracting said run-length counter value as a decodecount, iii. determining a decoded pixel value based on the decode value,iv. placing the decoded pixel value in a decoded image decode countnumber of times; (i) displaying said decoded image; (j) inputting asubsequent array of encoded data representing said subsequent image; (k)repeating steps (h) through (j) for at least a subset of said subsequentimages.
 12. The method of claim 11 wherein said decode pixel valuecomprises the decode value.
 13. The method of claim 11 wherein saiddecode pixel value is obtained from a decode table.
 14. The method ofclaim 4, the subset of all the pixels having dimensions less than orequal to 320 by
 240. 15. The method of claim 8, wherein the lines ofsaid encode table are randomly ordered forming an encryption table sothat the direct correlation between the original values and theirrepresentative codes are encrypted.
 16. The method of claim 13 whereinthe lines of the decode table are ordered in a sequence matching acorresponding encryption table so that the correct final pixel valuesare displayed.
 17. A machine for compressing a plurality of video frameswhich make up a video signal, comprising: (a) video digitizer configuredto digitizing a frame from said video frames; (b) a video memory whichis able to receive a plurality of pixels from said video digitizer; (c)an encoding circuit for compressing, according to the method of claim 1,said plurality of pixels; (d) a memory which is able to store saidencoded data; and (e) an input/output device.
 18. The machine of claim17 wherein said input/output device is a storage medium.
 19. The machineof claim 17 wherein said input/output device is a communicationtransmission channel.
 20. A machine for compressing a plurality of videoframes which make up a video signal, comprising: (a) video digitizerconfigured to digitizing a frame from said video frames; (b) a videomemory which is able to receive a plurality of pixels from said videodigitizer; (c) an encoding circuit for compressing, according to themethod of claim 9, said plurality of pixels; (d) a memory which is ableto store said encoded data; and (e) an input/output device.
 21. Amachine for decompressing a stream of encoded data that represents avideo signal, comprising: (a) an input/output device for reading saidstream of encoded data; (b) a decoding circuit for decompressing saidstream of encoded data according to the method of claim 11; and (c) amemory that is able to store an image comprising said stream of pixelvalues that can be displayed as frames of a video sequence.
 22. Amachine for decompressing a stream of encoded data that represents avideo signal, comprising: (a) an input/output device for reading saidstream of encoded data; (b) a decoding circuit for decompressing saidstream of encoded data according to the method of claim 13; and (c) amemory that is able to store an image comprising said stream of pixelvalues that can be displayed as frames of a video sequence.